Technical

Some of the business objects, especially the pages and the widgets, are renderable, i.e. they are convertible to HTML. The plugins responsible for that conversion are usually the .renderer.html. When a user requests a page created by i-Publisher, the request is processed by the HtmlViewerServlet , which calls the renderer of the page. There are different ways to render the page bean, i.e. to convert the page region tree into HTML. The rendering method is chosen for the whole site and not for each individual page. The rendering methods are listed in the ISite.ERenderer enumerator. They are:

• css – renders the region using a CSS layout;

• table – renders each region as a table (nested tables);

• jquery – uses a jquery layout, i.e. uses jquery plugins to determine the dimensions and position of each region.

For each rendering method there is a corresponding page renderer. All page renderers implement the com.tetracom.atlas.iviewer.renderer.page.api.IPageRenderer interface. Which renderer will be called is determined by an adapter, which adapts the renderer method to an IPageRenderer object. There is an abstract class, com.tetracom.atlas.iviewer.renderer.page.abstr.internal.APageRenderer, which all page renderers extend. Different page renderers provide different velocity templates for rendering each region and the page itself. However, the majority of the work is done in the abstract class. First, the page region is traversed and all widgets for rendering (some of them may not be rendered – depending on their visibility) are gathered. Then they are rendered asynchronously in different treads. The page renderer waits until all widgets are rendered and then renders the region (and the whole region tree respectively). The last step is rendering the page itself with all the necessary metadata (SEO properties, if defined), styles and scripts coming from the widgets.

The service managing the widget rendering is the com.tetracom.atlas.widget.renderer.api.IWidgetRenderer. This is a collective service which manages the specific renderers for different widgets. Each widget should be adaptable to the com.tetracom.atlas.widget.renderer.api.ISpecificWidgetRenderer service. This service provides the HTML content of the widget and its head addons. These addons are styles and scripts that should be placed in the head tag of the page, instead of the body, where the real page content (the widgets) is placed. Thus, the head addons are gathered separately from the widget's HTML content. The widget's addons are provided as a map with a fixed set of keys. There are four different types of head addons (four possible keys) defined in the

com.tetracom.atlas.widget.renderer.api.IWidgetRenderer.HeadAddOn enumerator:

• JavaScript – this key is used for including additional JavaScript files. In this case, just the source path of the file should be provided;

• CascadingStylesheet – this key is used when the source path of a CSS file is provided;

• OnDocumentReadyFunction – this key is used for simple JavaScript functions (usually content dependent). The value marked by this key is placed directly into a script tag in the head of the page;

• LoadContentOnScroll –this key  performs a specific JavaScript function if there are suitable widgets.

The custom CSS styles for all widgets (defined in the page region) is also collected and placed in a style tag in the head.

The IWidgetRenderer allows the widget to be rendered either synchronously, i.e. the ISpecificWidgetRenderer is called directly from the page renderer, or asynchronously – a div with a specific id is placed in the page instead of the real widget's content and some JavaScript is added to the page through the head addons. Thus, the widget's content may be loaded by the com.tetracom.atlas.widget.renderer.internal.http.WidgetRendererServlet after the content of the page itsel fis already loaded.